@tpietzsch currently this handles the reading case in a way I'm happy with.

However, I think the batching branch is missing an atomic write method that uses VolatileReadData. perhaps a void write(String path, ReadData readData); method? If we have that, than we can apply similar logic there to attempt writing without locks. That may be trickier, in that we don't want to write if someone already has the lock, just if the operation is not supported.

another this I did is remove the try / catch / return null for createReadData. It can't return null if we use it in try-with-resource blocks or you get a NPE. And we DO handle already N5NoSuchKeyException and return null in places that call createReadData so we should just the N5NoSuchKeyException bubble up to the ultimate caller.

another this I did is remove the try / catch / return null for createReadData. It can't return null if we use it in try-with-resource blocks or you get a NPE. And we DO handle already N5NoSuchKeyException and return null in places that call createReadData so we should just the N5NoSuchKeyException bubble up to the ultimate caller.

That isn't true. There will be no NPE in try-with-resources if the Closable is null.
At least this works for me:

public class ClosableNPETest {
	static class MyClosable implements AutoCloseable {
		@Override
		public void close() {
			System.out.println("MyClosable.close");
		}
	}

	static MyClosable create() {
//		return new MyClosable();
		return null; // this works fine
	}

	public static void main(String[] args) {
		try (MyClosable c = create()) {
			System.out.println("doing something with " + c);
		}
		System.out.println("done");
	}
}

another this I did is remove the try / catch / return null for createReadData. It can't return null if we use it in try-with-resource blocks or you get a NPE. And we DO handle already N5NoSuchKeyException and return null in places that call createReadData so we should just the N5NoSuchKeyException bubble up to the ultimate caller.

That isn't true. There will be no NPE in try-with-resources if the Closable is null. At least this works for me:

public class ClosableNPETest {
	static class MyClosable implements AutoCloseable {
		@Override
		public void close() {
			System.out.println("MyClosable.close");
		}
	}

	static MyClosable create() {
//		return new MyClosable();
		return null; // this works fine
	}

	public static void main(String[] args) {
		try (MyClosable c = create()) {
			System.out.println("doing something with " + c);
		}
		System.out.println("done");
	}
}

Your example is too trivial. The NPE arrises because the block is still executed. in your example, you are only using c as String + null which is fine. but if you try to call a method on c in the block, you will get an NPE, and that is always the case that we want to use methods on the Closable returned from the createReadData method.

modifying your example, and the output:

public static void main(String[] args) {
	try (MyClosable c = create()) {
		System.out.println("doing something with " + c);
		c.toString();
	}
	System.out.println("done");
}

doing something with null
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.toString()" because "c" is null
	at org.janelia.saalfeldlab.n5.N5Writer$ClosableNPETest.main(N5Writer.java:485)

Oh, then I misunderstood.

It can't return null if we use it in try-with-resource blocks or you get a NPE.

I thought that you mean the try-with-resources will try to close() the null. Instead you just meant

It can't return null if we use it in try-with-resource blocks or you get a NPE.

But then there is no problem.
The null behaviour is documented

If we decide to let pva.get(key) throw the N5NoSuchKeyException, then the easiest solution would be to just wrap it in a static method that turns it into null, replicating the current behaviour for ease of use in DefaultDatasetAccess. That seems pointless.

We (@cmhulbert , @tpietzsch ) discussed having PositionValueAccess catching the NoSuchKeyException from the wrapped KeyValueAccess and returning null